home *** CD-ROM | disk | FTP | other *** search
/ Halting the Hacker - A P…uide to Computer Security / Halting the Hacker - A Practical Guide to Computer Security.iso / rfc / rfc1362.txt < prev    next >
Text File  |  1997-04-01  |  30KB  |  731 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           M. Allen
  8. Request for Comments: 1362                                  Novell, Inc.
  9.                                                           September 1992
  10.  
  11.  
  12.                Novell IPX Over Various WAN Media (IPXWAN)
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  It does
  17.    not specify an Internet standard.  Distribution of this memo is
  18.    unlimited.
  19.  
  20. Abstract
  21.  
  22.    This document describes how Novell IPX operates over various WAN
  23.    media.  Specifically, it describes the common "IPX WAN" protocol
  24.    Novell uses to exchange necessary router to router information prior
  25.    to exchanging standard IPX routing information and traffic over WAN
  26.    datalinks.
  27.  
  28. Table of Contents
  29.  
  30.    1.  Introduction .................................................  1
  31.    1.1. Operation Over PPP ..........................................  2
  32.    1.2. Operation Over X.25 Switched Virtual Circuits ...............  2
  33.    1.3. Operation Over X.25 Permanent Virtual Circuits ..............  2
  34.    1.4. Operation Over Frame Relay ..................................  3
  35.    1.5. Operation Over Other WAN Media ..............................  3
  36.    2.  Glossary Of Terms ............................................  3
  37.    3.  IPX WAN Protocol Description .................................  4
  38.    4.  Information Exchange Packet Formats ..........................  5
  39.    4.1. Timer Request Packet ........................................  6
  40.    4.2. Timer Response Packet .......................................  8
  41.    4.3. Information Request Packet .................................. 10
  42.    4.4. Information Response Packet ................................. 12
  43.    5.  References ................................................... 12
  44.    6.  Security Considerations ...................................... 13
  45.    7.  Author's Address.............................................. 13
  46.  
  47. 1. Introduction
  48.  
  49.    This document describes how Novell IPX operates over various WAN
  50.    media. It is strongly motivated by a desire for IPX to treat ALL wide
  51.    area links in the same manner. Sections 3 and 4 describe this common
  52.    "IPX WAN" protocol.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Allen                                                           [Page 1]
  59.  
  60. RFC 1362                         IPXWAN                   September 1992
  61.  
  62.  
  63.    IPX WAN protocol operation begins immediately after link
  64.    establishment. While IPX is a connectionless datagram protocol, WANs
  65.    are often connection-oriented.  Different WANs have different methods
  66.    of link establishment. The subsections of section 1 of this document
  67.    describe what link establishment means to IPX for different media.
  68.    They also describe other WAN-media-dependent aspects of IPX
  69.    operation, such as protocol identification, frame encapsulation, and
  70.    link tear down.
  71.  
  72. 1.1 Operation Over PPP
  73.  
  74.    IPX uses PPP [1] when operating over point-to-point synchronous and
  75.    asynchronous networks.
  76.  
  77.    With PPP, link establishment means the IPX NCP [4] reaches the Open
  78.    state. NetWare IPX will reject all NCP options, and uses normal frame
  79.    encapsulation as defined by PPP. The IPXWAN protocol MUST NOT occur
  80.    until the IPX NCP reaches the Open state.
  81.  
  82.    PPP allows either side of a connection to stop forwarding IPX if one
  83.    end sends an IPXCP or an LCP Terminate-Request. When a router detects
  84.    this, it will immediately reflect the lost connectivity in its
  85.    routing information database instead of naturally aging it out.
  86.  
  87. 1.2 Operation over X.25 Switched Virtual Circuits
  88.  
  89.    With X.25, link establishment means successfully opening an X.25
  90.    virtual circuit.  As specified in RFC-1356, "Multiprotocol
  91.    Interconnect on X.25 and ISDN in the Packet Mode" [2], the protocol
  92.    identifier 0x800000008137 is used in the X.25 Call User Data field of
  93.    the Call Request frame, and indicates that the virtual circuit will
  94.    be devoted to IPX.
  95.  
  96.    Furthermore, each IPX packet is encapsulated directly in X.25 data
  97.    frame sequences without additional framing.
  98.  
  99.    Either side of the virtual circuit may close it, thereby tearing down
  100.    the IPX link. When a router detects this, it will immediately reflect
  101.    the lost connectivity in its routing information database instead of
  102.    naturally aging it out.
  103.  
  104. 1.3 Operation over X.25 Permanent Virtual Circuits
  105.  
  106.    The nature of X.25 PVC's is that no call request is made.  When the
  107.    router is informed that X.25 Layer 2 is up, the router should assume
  108.    that link establishment is complete.
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Allen                                                           [Page 2]
  115.  
  116. RFC 1362                         IPXWAN                   September 1992
  117.  
  118.  
  119.    Each IPX packet is encapsulated in an X.25 data frame sequence
  120.    without additional framing. Novell IPX assumes a particular X.25
  121.    permanent circuit is devoted to the use of IPX.
  122.  
  123.    If a router receives a layer 2 error condition (e.g., X.25 Restart),
  124.    it should reflect lost connectivity for the permanent circuits in its
  125.    routing information database and re-perform the necessary steps to
  126.    obtain a full IPX connection.
  127.  
  128. 1.4 Operation over Frame Relay
  129.  
  130.    Novell conforms to RFC-1294, "Multiprotocol Interconnect over Frame
  131.    Relay" [3] for frame relay service and packet encapsulation.
  132.    Currently, Novell has not stabilized the method for treating frame
  133.    relay connections - whether they treat the connections as LANs or
  134.    WANs.
  135.  
  136. 1.5 Operation over other WAN media
  137.  
  138.    Additional WAN media will be added here as specifications are
  139.    developed.
  140.  
  141. 2. Glossary Of Terms
  142.  
  143. Primary Network Number:
  144.  
  145.       Every IPX WAN router has a "primary network number". This is an
  146.       IPX network number unique to the entire internet.  This number
  147.       will be a permanently assigned network number for the router.
  148.       Those readers familiar with NetWare 3.x servers should realize
  149.       that this is the "Internal" network number.
  150.  
  151. Router Name:
  152.  
  153.       Every IPX WAN router must have a "Router Name". This is a symbolic
  154.       name given to the router. Its purpose is to allow routers to know
  155.       who they are connected to after link establishment - particularly
  156.       for network management purposes.  A symbolic name conveys more
  157.       information to an operator than a set of numbers. The symbolic
  158.       name should be between 1 and 47 characters in length containing
  159.       the characters 'A' through 'Z', underscore (_), hyphen (-) and
  160.       "at" sign (@). The string of characters should be followed by a
  161.       null character (byte of zero) and padded to 48 characters using
  162.       the null character.  Those readers familiar with NetWare 3.x
  163.       servers should realize that the file server name is the Router
  164.       Name.
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Allen                                                           [Page 3]
  171.  
  172. RFC 1362                         IPXWAN                   September 1992
  173.  
  174.  
  175. 3. IPX WAN Protocol Description
  176.  
  177.    IPX WAN links have the concept of a LINK MASTER and a LINK SLAVE.
  178.    This relationship is decided upon based on information contained
  179.    within the first IPX packets transferred across the WAN link.
  180.  
  181.    After link establishment, both sides of the link send "Timer Request"
  182.    packets and start a timer waiting for a "Timer Response". These
  183.    "Timer Request" packets are sent every 20 seconds until a response is
  184.    received or a time-out occurs trying to initialize a connection (the
  185.    timer is restarted each time a new "Timer Request" is sent). The
  186.    time-out should be configurable, and is normally about one minute.
  187.    This is directly dependent on the call setup time for the connection.
  188.    If a time-out occurs, the router issues a disconnect on the offending
  189.    connection and optionally attempts to retry the connection.
  190.  
  191.    When a "Timer Request" is received, the router with the lowest
  192.    primary network number MUST respond with a "Timer Response" packet -
  193.    and become the "Slave" of the link. If the "Slave" determines that it
  194.    cannot support any of the Routing Types included in the "Timer
  195.    Request" packet, the "Slave" should issue a disconnect on the
  196.    connection being established. The "Master" of the link (determined
  197.    when a "Timer Response" packet is received) is responsible for
  198.    defining the network number that is to be used as a common network
  199.    number for the new WAN link, and for calculating the RIP transport
  200.    time that will be advertized to other RIP routers for the new link.
  201.    This is calculated by stopping the timer which was started when a
  202.    "Timer Request" was initiated and applying the algorithm in section
  203.    4.2.
  204.  
  205.    To allow this, both sides of the link MUST have an adequate pool of
  206.    WAN network numbers (unique within the internetwork) available to be
  207.    assigned to the link when the call is fully completed. The "Master"
  208.    of the link MUST then select a network number and construct an
  209.    "Information Request" packet containing the calculated link delay,
  210.    the common network number, and its own router name. On receiving this
  211.    packet, the "Slave" MUST turn the packet around, overwrite the router
  212.    name and node identifier and send an "Information Response".
  213.  
  214.    After the "Master" has received the "Information Response" and the
  215.    "Slave" has received the "Information Request", standard IPX RIP and
  216.    SAP packets are transferred across the WAN link, as currently defined
  217.    for LAN links. The "IPX Router Specification" [5] contains
  218.    information describing the Novell RIP/SAP protocol for third party
  219.    developers.
  220.  
  221.    Note that the "Information Request" and "Information Response"
  222.    packets are specific to the "Routing Type"=0 information exchanges.
  223.  
  224.  
  225.  
  226. Allen                                                           [Page 4]
  227.  
  228. RFC 1362                         IPXWAN                   September 1992
  229.  
  230.  
  231.    With this routing type, no retransmission is made of any of the
  232.    Information packets. If a response has not been received within the
  233.    predefined time-out period, a disconnect is issued on the link, and
  234.    the link can optionally be attempted later.
  235.  
  236.    If a router detects an error for which no suitable protocol response
  237.    exists (e.g., unable to allocate a network number), the link should
  238.    be terminated according to the relevant media specification.
  239.  
  240.    Under certain circumstances, particularly on X.25 permanent circuits,
  241.    it is only possible to detect the remote router went away when it
  242.    comes back up again.  In this case, one side of the link receives a
  243.    Timer Request packet when IPX is in a fully connected state.  The
  244.    side receiving the Timer Request MUST realize that a problem
  245.    occurred, and revert to the IPX link establishment phase.
  246.    Furthermore, the routing information learned from this connection
  247.    should be immediately discarded.
  248.  
  249. 4. Information Exchange Packet Formats
  250.  
  251.    All IPX WAN information exchange packets conform to the standard
  252.    Novell IPX packet format. The packets use the IPX defined packet type
  253.    04 defining a Packet Exchange Packet. The socket number 0x9004 is a
  254.    Novell reserved socket number for exclusive use with IPX WAN
  255.    information exchange. IPX defines that a network number of 0 is
  256.    interpreted as being a local network of unknown number that requires
  257.    no routing. This feature is of use to us in transferring these
  258.    packets before the common network number is exchanged. Some routers
  259.    need to know a "Node Number" (or MAC address) for each node on a
  260.    link. Node numbers will be formed from the "WNode ID" field.  The
  261.    node number will be the 4 bytes of WNode ID followed by 2 bytes of
  262.    zero.
  263.  
  264.    Router Type number assignment. Other vendors IPX routing protocols
  265.    can make use of the IPXWAN protocol definition by obtaining Router
  266.    Types from Novell. This document will then include the new Router
  267.    Types (with the references to vendor protocol description documents).
  268.  
  269.    WOption Number assignment. These numbers only need to be assigned
  270.    from Novell for the "Timer Request" and "Timer Response" packets.
  271.    Other packet types (e.g., the "Information Request" packets, are
  272.    dependent on the "Router Type" negotiated and can contain any (vendor
  273.    defined) packet type other than 0 or 1. WOption numbers in these
  274.    packets are then defined by the vendor defining the Routing Type. The
  275.    same packet format should still be maintained.
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Allen                                                           [Page 5]
  283.  
  284. RFC 1362                         IPXWAN                   September 1992
  285.  
  286.  
  287. 4.1 Timer Request Packet
  288.  
  289.    +---------------------------------------------------------------+
  290.    | Checksum         | FF FF             | Always FFFF            |
  291.    | Packet Length    | 02 40             | Max IPX size (576 bytes|
  292.    |                  |                   | Hi Lo order)           |
  293.    | Trans Control    | 00                | Hops traversed         |
  294.    | Packet Type      | 04                | Packet Exchange Packet |
  295.    | Dest Net #       | 00 00 00 00       | Local Network          |
  296.    | Dest Node #      | FF FF FF FF FF FF | Broadcast              |
  297.    | Dest Socket #    | 90 04             | Reserved WAN socket    |
  298.    | Source Net #     | 00 00 00 00       | Local Network          |
  299.    | Source Node #    | 00 00 00 00 00 00 | Set to zero            |
  300.    | Source Socket #  | 90 04             | Reserved WAN socket    |
  301.    |------------------+-------------------+------------------------|
  302.    | WIdentifier      | 57 41 53 4D       | Confidence identifier  |
  303.    | WPacket Type     | 00                | Timer Request          |
  304.    | WNode ID         | xx xx xx xx       | Primary Net # of       |
  305.    |                  |                   | sending router         |
  306.    |                  |                   | (Hi Lo order)          |
  307.    | WSequence #      | xx                | Sequence start at 0    |
  308.    | WNum Options     | 02                | 2 Options follow       |
  309.    | WOption Number   | 00                | Define Routing Type    |
  310.    | WAccept Option   | 01                | 0=No,1=Yes,3=Not Applic|
  311.    | WOption Data Len | 00 01             | Option length (Hi Lo)  |
  312.    | WOption Data     | 00                | IPX RIP/SAP Routing    |
  313.    | WOption Number   | FF                | Pad option             |
  314.    | WAccept Option   | 01                | 0=No,1=Yes,3=Not Applic|
  315.    | WOption Data Len | 02 0E             | Pad data length (Hi Lo)|
  316.    | WOption Data     | 00->FF's          | Repeated sequence of 00|
  317.    |                  |                   | through FF's.          |
  318.    +---------------------------------------------------------------+
  319.  
  320.    Note:
  321.         Timer Request packets will always be 576 bytes. However,
  322.         there should be no assumption made about the number of
  323.         options specified in this packet.
  324.  
  325.    After link establishment, Timer Request packets are sent by both
  326.    sides of the link. Each end starts their sequence number at zero.
  327.    Subsequent retries (every 20 seconds) will increment the value of
  328.    this sequence number.  Only a Timer Response packet with a sequence
  329.    number matching the last sent sequence number will be acted upon.
  330.  
  331.    When receiving this packet, the WNode ID should be compared to the
  332.    receiver's Primary Network #. If the WNode ID is larger than the
  333.    receiver's Primary Network #, a Timer Response packet should be sent,
  334.    and the receiver should become the link "Slave".
  335.  
  336.  
  337.  
  338. Allen                                                           [Page 6]
  339.  
  340. RFC 1362                         IPXWAN                   September 1992
  341.  
  342.  
  343.    Packets received on the reserved socket number not having the
  344.    WIdentifier set to the hexadecimal values noted above should be
  345.    discarded.
  346.  
  347. Routing Type Option:
  348.  
  349.    A routing type of zero (0) is the minimum interoperability
  350.    requirement (as defined by this document). A router ready to send a
  351.    Timer Response (and receiving a routing type of zero) MUST respond
  352.    with a routing type of zero. A router ready to send a Timer Response
  353.    (and receiving routing types not matching a supported value) SHOULD
  354.    respond with a Routing Type of zero indicating support for the
  355.    minimum common protocol.
  356.  
  357.    Note that multiple Routing Type Options can be included in the Timer
  358.    Request packet if the router supports multiple routing methods for
  359.    IPX. The included Router Types MUST include and support this type
  360.    zero option.
  361.  
  362. Accept Option (for Routing Type and PAD options):
  363.  
  364.    This field MUST be set to YES if the option is supported, and NO if
  365.    an option is not supported. A Timer Response MUST respond with ONLY
  366.    one Router Type set to YES.
  367.  
  368. PAD Option:
  369.  
  370.    This option will normally be the last entry in the packet.  Its sole
  371.    purpose is to fill the IPX packet to be 576 bytes.  The pad option
  372.    data will contain a repeating sequence of zero's through 0xFF's. This
  373.    should stop compression modems from collapsing the packet and
  374.    destroying the link delay calculation.
  375.  
  376.    Currently Assigned WOption Numbers (Timer Request Packet):
  377.        Routing Type Option = 0x00;     Option Length = 0001
  378.            Current option data values:
  379.                0       Novell RIP/SAP routing with network
  380.                        number assigned to the link.
  381.  
  382.        PAD Type Option     = 0xFF;     Option Length = Variable
  383.  
  384.        Compression Option  = 0x80;     Option Length = Variable
  385.                          (length dependent on compression type)
  386.            Current option data values:
  387.                Byte 1  Compression type
  388.                    0 = Telebit compression (length=3) [6]
  389.                    Telebit Byte 2 - Compression options
  390.                    Telebit Byte 3 - Number compression slots
  391.  
  392.  
  393.  
  394. Allen                                                           [Page 7]
  395.  
  396. RFC 1362                         IPXWAN                   September 1992
  397.  
  398.  
  399. 4.2. Timer Response Packet
  400.  
  401.    +---------------------------------------------------------------+
  402.    | Checksum         | FF FF             | Always FFFF            |
  403.    | Packet Length    | 02 40             | Max IPX size (576 bytes|
  404.    |                  |                   | Hi Lo order)           |
  405.    | Trans Control    | 00                | Hops traversed         |
  406.    | Packet Type      | 04                | Packet Exchange Packet |
  407.    | Dest Net #       | 00 00 00 00       | Local Network          |
  408.    | Dest Node #      | FF FF FF FF FF FF | Broadcast              |
  409.    | Dest Socket #    | 90 04             | Reserved WAN socket    |
  410.    | Source Net #     | 00 00 00 00       | Local Network          |
  411.    | Source Node #    | 00 00 00 00 00 00 | Set to zero            |
  412.    | Source Socket #  | 90 04             | Reserved WAN socket    |
  413.    |------------------+-------------------+------------------------|
  414.    | WIdentifier      | 57 41 53 4D       | Confidence identifier  |
  415.    | WPacket Type     | 01                | Timer Response         |
  416.    | WNode ID         | xx xx xx xx       | Primary Net # of       |
  417.    |                  |                   | sending router         |
  418.    |                  |                   | (Hi Lo order)          |
  419.    | WSequence #      | xx                | Same as Timer Request  |
  420.    |                  |                   | received               |
  421.    | WNum Options     | 02                | 2 Options follow       |
  422.    | WOption Number   | 00                | Define Routing Type    |
  423.    | WAccept Option   | 01                | 0=No,1=Yes,3=Not Applic|
  424.    | WOption Data Len | 00 01             | Option length (Hi Lo)  |
  425.    | WOption Data     | 00                | IPX RIP/SAP Routing    |
  426.    |                  |                   | (Minimum interoperating|
  427.    |                  |                   | requirement). Others   |
  428.    |                  |                   | may be defined by at a |
  429.    |                  |                   | later date by Novell   |
  430.    | WOption Number   | FF                | Pad option             |
  431.    | WAccept Option   | 01                | 0=No,1=Yes,3=Not Applic|
  432.    | WOption Data Len | 02 0E             | Pad data length (Hi Lo)|
  433.    | WOption Data     | 00->FF's          | Repeated sequence of 00|
  434.    |                  |                   | through FF's to stop   |
  435.    |                  |                   | compression modems     |
  436.    |                  |                   | doing any compression  |
  437.    |                  |                   | for link delay calc.   |
  438.    +---------------------------------------------------------------+
  439.  
  440.    The responses contained within this packet are as described in
  441.    section 4.1. Any unknown options or not supported options from the
  442.    Timer Request should have the WAccept Option set to NO.
  443.  
  444.    If the Timer Request packet contained more than one Router Type
  445.    option and the "Slave" supports all the options, the "Slave" should
  446.    set the WAccept Option to NO on all Router Types except the Routing
  447.  
  448.  
  449.  
  450. Allen                                                           [Page 8]
  451.  
  452. RFC 1362                         IPXWAN                   September 1992
  453.  
  454.  
  455.    Type which is to be adopted. The "Master" of the link will then adopt
  456.    the routing option specified with the YES setting and complete
  457.    further information exchanges according to that routing standard.
  458.  
  459.    This packet should contain the same sequence number as the received
  460.    Timer Request. This packet should ONLY be sent by the router
  461.    determining themselves to be the "Slave" of the link.
  462.  
  463.    Currently Assigned WOption Numbers (Timer Response Packet):
  464.        Routing Type Option = 0x00;     Option Length = 0001
  465.            Current option data values:
  466.               0       Novell RIP/SAP routing with network
  467.                       number assigned to the link.
  468.  
  469.        PAD Type Option     = 0xFF;     Option Length = Variable
  470.  
  471.        Compression Option  = 0x80;     Option Length = Variable
  472.                          (length dependant on compression type)
  473.            Current option data values:
  474.                Byte 1  Compression type
  475.                    0 = Telebit compression (length=3) [6]
  476.                    Telebit Byte 2 - Compression options
  477.                    Telebit Byte 3 - Number compression slots
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Allen                                                           [Page 9]
  507.  
  508. RFC 1362                         IPXWAN                   September 1992
  509.  
  510.  
  511. 4.3. RIP/SAP Information Request Packet (Router Type=0 Only)
  512.  
  513.    +---------------------------------------------------------------+
  514.    | Checksum         | FF FF             | Always FFFF            |
  515.    | Packet Length    | 00 63             | Size of header+data    |
  516.    |                  |                   | (Hi Lo order)          |
  517.    | Trans Control    | 00                | Hops traversed         |
  518.    | Packet Type      | 04                | Packet Exchange Packet |
  519.    | Dest Net #       | 00 00 00 00       | Local Network          |
  520.    | Dest Node #      | FF FF FF FF FF FF | Broadcast              |
  521.    | Dest Socket #    | 90 04             | Reserved WAN socket    |
  522.    | Source Net #     | 00 00 00 00       | Local Network          |
  523.    | Source Node #    | 00 00 00 00 00 00 | Set to zero            |
  524.    | Source Socket #  | 90 04             | Reserved WAN socket    |
  525.    |------------------+-------------------+------------------------|
  526.    | WIdentifier      | 57 41 53 4D       | Confidence identifier  |
  527.    | WPacket Type     | 02                | Information Request    |
  528.    | WNode ID         | xx xx xx xx       | Primary Net # of       |
  529.    |                  |                   | sending router         |
  530.    |                  |                   | (Hi Lo order)          |
  531.    | WSequence #      | 00                | Sequence start at 0    |
  532.    | WNum Options     | 01                | 1 Option to follow     |
  533.    | WOption Number   | 01                | Define IPX RIP/SAP     |
  534.    |                  |                   | info exchange          |
  535.    | WAccept Option   | 01                | 0=No,1=Yes,3=Not Applic|
  536.    | WOption Data Len | 00 36             | Option length (Hi Lo)  |
  537.    | WOption Data     |                   |                        |
  538.    |  Link Delay      | xx xx             | Hi Lo link delay in    |
  539.    |                  |                   | milli seconds (see     |
  540.    |                  |                   | below for calculation) |
  541.    |  Common Net #    | xx xx xx xx       | Hi Lo Common Network # |
  542.    |  Router Name     | xx (x 48 decimal) | Router name - as defned|
  543.    |                  |                   | in section 2.          |
  544.    +---------------------------------------------------------------+
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Allen                                                          [Page 10]
  563.  
  564. RFC 1362                         IPXWAN                   September 1992
  565.  
  566.  
  567. Calculation of link delay is performed as follows:
  568.  
  569.    // Start_time is a time stamp when Timer Request sent out
  570.    // End_time is a time stamp when a Timer Response is
  571.    // received.
  572.    link_delay = end_time - start_time; // 1/18th second
  573.    // We are on a slow net, so add some biasing to help stop
  574.    // multiple workstation sessions timing out on the link
  575.    if (link_delay < 1)
  576.    {
  577.        link_delay = 1;
  578.    }/*IF*/
  579.    link_delay *= 6;   // Add the biasing
  580.    link_delay *= 55;  // Convert link delay to milliseconds
  581.  
  582.    The "Link Delay" is used as the network transport time when
  583.    advertized in the IPX RIP packet tuple for the network entry "Common
  584.    Net #". For a consistent network, a common link delay is required at
  585.    both ends of the link and is calculated by the link "Master".
  586.  
  587.    The Common Net # is supplied by the link "Master". This number must
  588.    be unique in the connected internetwork. Each WAN call requires a
  589.    separate number.
  590.  
  591.    Currently only a single option is defined for the "Information
  592.    Request" packet for Routing Type=0.
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Allen                                                          [Page 11]
  619.  
  620. RFC 1362                         IPXWAN                   September 1992
  621.  
  622.  
  623. 4.4. RIP/SAP Information Response Packet (Router Type=0 Only)
  624.  
  625.    +---------------------------------------------------------------+
  626.    | Checksum         | FF FF             | Always FFFF            |
  627.    | Packet Length    | 00 63             | Size of header+data    |
  628.    |                  |                   | (Hi Lo Order)          |
  629.    | Trans Control    | 00                | Hops traversed         |
  630.    | Packet Type      | 04                | Packet Exchange Packet |
  631.    | Dest Net #       | 00 00 00 00       | Local Network          |
  632.    | Dest Node #      | FF FF FF FF FF FF | Broadcast              |
  633.    | Dest Socket #    | 90 04             | Reserved WAN socket    |
  634.    | Source Net #     | 00 00 00 00       | Local Network          |
  635.    | Source Node #    | 00 00 00 00 00 00 | Set to zero            |
  636.    | Source Socket #  | 90 04             | Reserved WAN socket    |
  637.    |------------------+-------------------+------------------------|
  638.    | WIdentifier      | 57 41 53 4D       | Confidence identifier  |
  639.    | WPacket Type     | 03                | Information Response   |
  640.    | WNode ID         | xx xx xx xx       | Primary Net # of       |
  641.    |                  |                   | sending router         |
  642.    |                  |                   | (Hi Lo order)          |
  643.    | WSequence #      | 00                | Sequence start at 0    |
  644.    | WNum Options     | 01                | 1 Option to follow     |
  645.    | WOption Number   | 01                | Define IPX RIP/SAP     |
  646.    |                  |                   | info exchange          |
  647.    | WAccept Option   | 01                | 0=No,1=Yes,3=Not Applic|
  648.    | WOption Data Len | 00 36             | Option length (Hi Lo)  |
  649.    | WOption Data     |                   |                        |
  650.    |  Link Delay      | xx xx             | Hi Lo link delay (as   |
  651.    |                  |                   | received in Info Requ) |
  652.    |  Common Net #    | xx xx xx xx       | Hi Lo Common Network # |
  653.    |                  |                   | (as received in Info   |
  654.    |                  |                   | request)               |
  655.    |  Router Name     | xx (x 48 decimal) | Router name - as defned|
  656.    |                  |                   | in section 2.          |
  657.    +---------------------------------------------------------------+
  658.  
  659.    The responses contained within this packet are as described in
  660.    section 4.3.
  661.  
  662. 5. References
  663.  
  664.    [1] Simpson, W., "The Point-to-Point Protocol (PPP) for the
  665.        Transmission of Multi-protocol Datagrams over Point-to-Point
  666.        Links", RFC 1331, May 1992.
  667.  
  668.    [2] Malis, A., Robinson, D., and R. Ullman, "Multiprotocol
  669.        Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356,
  670.        August 1992.
  671.  
  672.  
  673.  
  674. Allen                                                          [Page 12]
  675.  
  676. RFC 1362                         IPXWAN                   September 1992
  677.  
  678.  
  679.    [3] Bradley, T., Brown, C., and A. Malis, "Multiprotocol Interconnect
  680.        over Frame Relay", RFC 1294, January 1992.
  681.  
  682.    [4] Simpson, W., "The PPP Internetwork Packet Exchange Control
  683.        Protocol (IPXCP) Compromise Version", Work in Progress.
  684.  
  685.    [5] Novell IPX Router Specification. Novell Part Number 107-000029-
  686.        001. (Note:  Currently, this document is only available as part
  687.        of a Novell developers program as part of an SDK. Novell Labs,
  688.        Provo (UT) should be able to provide more information on this
  689.        document.)
  690.  
  691.    [6] Lewis, M., Telebit Corp. "IPX Header Compression based on Van
  692.        Jacobson Header Compression for TCP/IP", Work in Progress,
  693.        contact: (mlewis@telebit.com).
  694.  
  695. 6. Security Considerations
  696.  
  697.        Security issues are not discussed in this memo.
  698.  
  699. 7. Author's Address
  700.  
  701.        Michael Allen
  702.        Novell, Inc.
  703.        2180 Fortune Drive
  704.        San Jose, CA 95131
  705.  
  706.        EMail: MALLEN@NOVELL.COM
  707.  
  708.        Chair's Address:
  709.  
  710.        The working group can be contacted via the current chair:
  711.  
  712.        Brian Lloyd
  713.        Lloyd & Associates
  714.        3420 Sudbury Road
  715.        Cameron Park, California 95682
  716.  
  717.        EMail: brian@ray.lloyd.com
  718.  
  719.        Phone: (916) 676-1147
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Allen                                                          [Page 13]
  731.